Пользователи ничего не замечают
Уже час нас атакуют 20-40 Gbps и 2-4 Mpps. Пользователи ничего не замечают :-)
Protect yourself by SYN flood
Distributed Denial of Service (DDoS) attacks are becoming increasingly commonplace as business becomes more and more dependent on delivering services over the Internet. One of the most common types of DDoS attacks is the well-known SYN-flood attack. It is a basic end-host resource attack designed to bring your server to its knees. As a result, your server is unable to properly handle any new incoming connection requests.
SYN Protection in the past
In the past, SYN attacks, by major vendor, was mitigated using conntrack filtering on commodity or AICS hardware. With Netfilter’s connection tracking system (conntrack), we can start filtering out false SYN-ACK and ACK packets before they hit the “listen” state lock. The conntrack system actually has a scalability problem (like the “listen” lock) when it comes to creating (or deleting) connections, which the SYN-flood will hit.
Even after fixing the conntrack lock, the SYN packets will still be sent to the socket causing the “listen” socket lock to occur. The normal mitigation technique is to send SYN-cookies and avoid creating any state until the SYN-ACK packet is seen.
Unfortunately, SYN-cookies are sent under the same “listen” state lock, so the mitigation does not solve the scalability issue. How these limitations can be worked around will be discussed later.
SYNPROXY, New Filtering Era
With SYNPROXY we can increase 20x performance then old technique removing the “listen state lock” part catching packets that the connection tracking system has categorized as “INVALID” and not part of a known connection state. The matching against existing conntrack entries is very fast and completely scalable. The conntrack system actually does lockless RCU (read-copy update) lookups for existing connections.
Essentially, this solves all other TCP-flooding packets except SYN-flooding.
But NOW, How we can solve SYN-flooding?
SYNPROXY essentially does parallel SYN-cookies and not create a conntrack entry before the SYN-ACK packet is received thus avoiding the conntrack new connections lock. Once the initial connection is established the normal conntrack system will take over and do all the needed forwarding.
If you have CentOS 7 or any distribution with kernel > 3.13 and iptables 1.4.21 you have this module built-in.
To enable it we need to tweak sysctl.conf. Insert in /etc/sysctl.conf:
Now you can configure SYNPROXY using public online script avaiable here
github.com/netoptimizer/network-testing/blob/master/iptables/iptables_synproxy.sh
If you want configure yourself go head with these steps:
Step #1: In the “raw” table, we need to make sure connections that need protection don’t create new conntrack entries for SYN packets.
Step #2: Now we need to catch these packets and direct them to the SYNPROXY target module. To do this, use the following rule to catch UNTRACKED SYN and INVALID packets that contain the ACK from 3WHS (and also others, but they will fall-through).
Step #3: Catch the INVALID state packets that fell-through the SYNPROXY module and drop those. Basically, this will drop SYN-ACK based floods.
Considerations when using SYNPROXY
Enabling SYNPROXY does comes at a cost. The connection establishment phase is going to be slower due to the extra connection setup needed towards the end-host. When the end-host is localhost, then this extra step is obviously very fast but nonetheless adds latency.
The parameters to the SYNPROXY target module must match TCP options and settings supported by the end-host that the TCP connections are being proxied for. Detecting and setting this up is manually done per rule setting. (A helper tool “nfsynproxy” is part of iptables release 1.4.21). This unfortunately means the module cannot be easily deployed in DHCP-based firewall environments.
SYN Protection in the past
In the past, SYN attacks, by major vendor, was mitigated using conntrack filtering on commodity or AICS hardware. With Netfilter’s connection tracking system (conntrack), we can start filtering out false SYN-ACK and ACK packets before they hit the “listen” state lock. The conntrack system actually has a scalability problem (like the “listen” lock) when it comes to creating (or deleting) connections, which the SYN-flood will hit.
Even after fixing the conntrack lock, the SYN packets will still be sent to the socket causing the “listen” socket lock to occur. The normal mitigation technique is to send SYN-cookies and avoid creating any state until the SYN-ACK packet is seen.
Unfortunately, SYN-cookies are sent under the same “listen” state lock, so the mitigation does not solve the scalability issue. How these limitations can be worked around will be discussed later.
SYNPROXY, New Filtering Era
With SYNPROXY we can increase 20x performance then old technique removing the “listen state lock” part catching packets that the connection tracking system has categorized as “INVALID” and not part of a known connection state. The matching against existing conntrack entries is very fast and completely scalable. The conntrack system actually does lockless RCU (read-copy update) lookups for existing connections.
Essentially, this solves all other TCP-flooding packets except SYN-flooding.
But NOW, How we can solve SYN-flooding?
SYNPROXY essentially does parallel SYN-cookies and not create a conntrack entry before the SYN-ACK packet is received thus avoiding the conntrack new connections lock. Once the initial connection is established the normal conntrack system will take over and do all the needed forwarding.
If you have CentOS 7 or any distribution with kernel > 3.13 and iptables 1.4.21 you have this module built-in.
To enable it we need to tweak sysctl.conf. Insert in /etc/sysctl.conf:
#SYN cookies
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog=4096
net.ipv4.tcp_syn_retries=5
net.ipv4.tcp_synack_retries=2
#SYNPROXY REQ
net.netfilter.nf_conntrack_tcp_loose=0
net.netfilter.nf_conntrack_max=2000000
net.ipv4.tcp_timestamps=1
#OPTIMIZE TCP
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.netdev_max_backlog = 250000Now you can configure SYNPROXY using public online script avaiable here
github.com/netoptimizer/network-testing/blob/master/iptables/iptables_synproxy.sh
If you want configure yourself go head with these steps:
Step #1: In the “raw” table, we need to make sure connections that need protection don’t create new conntrack entries for SYN packets.
# iptables -t raw -I PREROUTING -i $DEV -p tcp -m tcp –syn –dport $PORT -j CT –notrackStep #2: Now we need to catch these packets and direct them to the SYNPROXY target module. To do this, use the following rule to catch UNTRACKED SYN and INVALID packets that contain the ACK from 3WHS (and also others, but they will fall-through).
# iptables -A INPUT -i $DEV -p tcp -m tcp –dport $PORT -m state –state INVALID,UNTRACKED -j SYNPROXY –sack-perm –timestamp –wscale 7 –mss 1460Step #3: Catch the INVALID state packets that fell-through the SYNPROXY module and drop those. Basically, this will drop SYN-ACK based floods.
# iptables -A INPUT -m state –state INVALID -j DROPConsiderations when using SYNPROXY
Enabling SYNPROXY does comes at a cost. The connection establishment phase is going to be slower due to the extra connection setup needed towards the end-host. When the end-host is localhost, then this extra step is obviously very fast but nonetheless adds latency.
The parameters to the SYNPROXY target module must match TCP options and settings supported by the end-host that the TCP connections are being proxied for. Detecting and setting this up is manually done per rule setting. (A helper tool “nfsynproxy” is part of iptables release 1.4.21). This unfortunately means the module cannot be easily deployed in DHCP-based firewall environments.
50% до 30 апреля
Подключили Arbor TMS.
Тех. работы закончены.
Готовы к отражению 100% атак на игровые серверы.
Скидка 50% до 30 апреля
Скидка 50% до 30 апреля — на игровой хостинг:
RUST, CS, SAMP, MTA, ARK, HurtWorld!
Промо код — Arbor
srvgame.ru
И не забываем!
В личном кабинете можно активировать партнерку.
10% ежемесячно cо всех платежей, Вам на баланс ;)
Подарите другу реф ссылку и промо код.
Читать дальше →
Dedicated Servers and KVM Cloud Servers - DDoS Filtering
High Performance KVM Cloud Servers
- 1 Core Processor / 512Mb DDR4 Memory / 10GB SSD Disk / 1TB Transfer / DDoS Protection / 1 IP
- 1 Core Processor / 1024Mb DDR4 Memory / 20GB SSD Disk / 3TB Transfer / DDoS Protection / 1 IP
- 2 Core Processor / 2048Mb DDR4 Memory / 30GB SSD Disk / 3TB Transfer / DDoS Protection / 1 IP
- 2 Core Processor / 4096Mb DDR4 Memory / 50GB SSD Disk / 4TB Transfer / DDoS Protection / 1 IP
DDoS Filtering PoPs
- London — Telehouse/Level3
- Frankfurt — Equinix FR5/Interxion/NewTelco
- Bucharest — Voxility IRD/NXData-1/NXData-2
- Washington — Equinix DC2
- Miami — Terremark, «NAP of the Americas»
- Los Angeles — Equinix LA1
- Intel Core i3-4170 / 8GB DDR3 / 120GB SSD/1TB HDD / 1Gbps
- Intel Core i5-4460 / 16GB DDR3 / 240GB SSD/1TB HDD / 1Gbps
- Intel Core i7-2600k / 32GB DDR3 / 2 x 120GB SSD / 1Gbps
- Intel Core i7-4790 / 32GB DDR3 / 240GB SSD/1TB HDD / 1Gbps
- Intel Xeon E3-1240V3 / 32GB DDR3 / 240GB SSD/1TB HDD / 1Gbps
- Intel Xeon E3-1270V3 / 32GB DDR3 / 240GB SSD/1TB HDD / 1Gbps
- Intel Core i7-6700K / 32GB DDR4 / 240GB SSD/1TB HDD / 1Gbps
- Intel Xeon E5-1650v3 / 16GB DDR4 ECC / 240GB SSD / 1Gbps
- Intel Core i7-6700K / 64GB DDR4 / 240GB SSD/1TB HDD / 1Gbps
- Intel Xeon E5-1650v3 / 64GB DDR4 ECC / 240GB SSD / 1Gbps
- Intel Xeon E5-1650v3 / 64GB DDR4 ECC / 240GB SSD / 1Gbps
- Intel Xeon E5-1650v3 / 64GB DDR4 ECC / 240GB SSD/1TB HDD / 1Gbps
zare.co.uk
DDoS-GUARD mitigated 110 Gbps DDoS attack on game server
On parle de VAC5 à VAC16 dans les 18 mois à venir
Bonjour,
Nous allons proposer le vRack sur le PCI/VPS. Le Public Cloud.
On va le dérouler en plusieurs étages:
1) d'abord, vous allez pouvoir créer un vrack entre les VM d'un
même DC
2) en suite, on va l’élargir (automatiquement) à tous les services
d'un même DC (SD+PCC+PCI/VPS)
3) puis multi-dc, mais sachant que le vrack 2 est déjà multi-dc
dés que le 2) est fait, ça sera multi-dc, juste on aura à changer
la techno entre les DC pour utiliser les 100G au lieu de Nx10G
Il faut compter 6 semaines entre le 1) et 3). Le 1) commence
la semaine prochaine. On attend le matos pour finir le 2) et
le 3) et complétement arrêter le vrack 2.0 qui va mourir au
profit de vrack 3: 100% vxlan de bout à bout.
Comment ça va marcher?
— Le vRack de PCI/VPS est un vrack standard. Un segment L2,
un mega bridge multi dc par client qui peut se terminer sur
chaque service chez ovh. C'est l'eth1 de serveurs dédiés si
on veut. Sur ce segment vous pouvez créer 4000 vlan. Par
exemple le vlan 123 c'est eth1.123.
Sur le PCI on vous configure un vlan spécifique par interface,
c'est à dire vous allez pouvoir configurer le vlan 123 sur eth1
directement. Pas besoin de faire eth1.123, le vlan 123 est déjà
specifié de notre côté. Plus tard, on va vous proposer aussi
tout les vrack entier sur une seule interface ethX puis vous
allez pouvoir configurer vous même les vlans que vous voulez
eth5.123 eth5.1984 etc.
toujours plus et moins cher
— En parallèle, nous travaillons sur l'accélération de traitement
de packets dans le PCI/VPS. Vous savez qu'Ovh a fait son
propre router à la base de X86. On gère 160Gbps/160Mpps
par châssis. On est en train de préparer la mise en place du
vR sur RBX1, un petit DC avec les Kimsufi où nous avons 80Gbps
de trafic Aujourd'hui, le routage est assuré par 2 ASR9001
avec 120Gbps de capa chaque. Demain, on aura 4x vR avec
4x160Gbps de capa et ceci pour 10% du prix des ASR9K
Cette même techno est portée dans les hosts de PCI/VPS
afin de supporter 10Gbps/10Mpps (25Gbps/25Mpps demain).
Il nous manque encore quelques devs mais pour fin mars
on devrait l’intégrer dans tous les hosts de PCI/VPS. Le gros
avantage est qu'un DDoS n'aura plus aucun impact sur les
hosts ni sur les VM hébergés sur ce host. Ça sera routé comme
un routeur vR.
Le cerise sur le gâteau: nous sommes en train d’intégrer
le VAC + l'Anti-DDoS GAME sur le vR. C'est à dire par défaut
on veut protéger tous les clients sans détecter les DDoS.
24/24 par défaut tous les packets sont analysés en input
et output. RBX1 sera le 1er à avoir cette techno et les autres
DC vont suivre. On devrait être 100% vR pour la fin 2016
et donc de faire x10 sur les capacités de nos DCs pour un
coût de 10%.
L'Anti-DDoS de vR sera porté sur les hosts PCI/VPS et donc
ça sera pareil pour les VPS, c'est à dire 100% de PCI et VPS
seront protégés 24/24.
On est en train de terminer le VAC4 pour GRA en se basant
sur le vR + Anti-DDoS. Le VAC4 sera comme le VAC1/2/3
sauf qu'il coutera 10% du prix. On va pouvoir donc le déployer
massivement dans nos 12 nouveaux DCs, sans limite de
capacité de traitement. On parle de VAC5 à VAC16 dans
les 18 mois à venir.
Amicalement
Octave
Nous allons proposer le vRack sur le PCI/VPS. Le Public Cloud.
On va le dérouler en plusieurs étages:
1) d'abord, vous allez pouvoir créer un vrack entre les VM d'un
même DC
2) en suite, on va l’élargir (automatiquement) à tous les services
d'un même DC (SD+PCC+PCI/VPS)
3) puis multi-dc, mais sachant que le vrack 2 est déjà multi-dc
dés que le 2) est fait, ça sera multi-dc, juste on aura à changer
la techno entre les DC pour utiliser les 100G au lieu de Nx10G
Il faut compter 6 semaines entre le 1) et 3). Le 1) commence
la semaine prochaine. On attend le matos pour finir le 2) et
le 3) et complétement arrêter le vrack 2.0 qui va mourir au
profit de vrack 3: 100% vxlan de bout à bout.
Comment ça va marcher?
— Le vRack de PCI/VPS est un vrack standard. Un segment L2,
un mega bridge multi dc par client qui peut se terminer sur
chaque service chez ovh. C'est l'eth1 de serveurs dédiés si
on veut. Sur ce segment vous pouvez créer 4000 vlan. Par
exemple le vlan 123 c'est eth1.123.
Sur le PCI on vous configure un vlan spécifique par interface,
c'est à dire vous allez pouvoir configurer le vlan 123 sur eth1
directement. Pas besoin de faire eth1.123, le vlan 123 est déjà
specifié de notre côté. Plus tard, on va vous proposer aussi
tout les vrack entier sur une seule interface ethX puis vous
allez pouvoir configurer vous même les vlans que vous voulez
eth5.123 eth5.1984 etc.
toujours plus et moins cher
— En parallèle, nous travaillons sur l'accélération de traitement
de packets dans le PCI/VPS. Vous savez qu'Ovh a fait son
propre router à la base de X86. On gère 160Gbps/160Mpps
par châssis. On est en train de préparer la mise en place du
vR sur RBX1, un petit DC avec les Kimsufi où nous avons 80Gbps
de trafic Aujourd'hui, le routage est assuré par 2 ASR9001
avec 120Gbps de capa chaque. Demain, on aura 4x vR avec
4x160Gbps de capa et ceci pour 10% du prix des ASR9K
Cette même techno est portée dans les hosts de PCI/VPS
afin de supporter 10Gbps/10Mpps (25Gbps/25Mpps demain).
Il nous manque encore quelques devs mais pour fin mars
on devrait l’intégrer dans tous les hosts de PCI/VPS. Le gros
avantage est qu'un DDoS n'aura plus aucun impact sur les
hosts ni sur les VM hébergés sur ce host. Ça sera routé comme
un routeur vR.
Le cerise sur le gâteau: nous sommes en train d’intégrer
le VAC + l'Anti-DDoS GAME sur le vR. C'est à dire par défaut
on veut protéger tous les clients sans détecter les DDoS.
24/24 par défaut tous les packets sont analysés en input
et output. RBX1 sera le 1er à avoir cette techno et les autres
DC vont suivre. On devrait être 100% vR pour la fin 2016
et donc de faire x10 sur les capacités de nos DCs pour un
coût de 10%.
L'Anti-DDoS de vR sera porté sur les hosts PCI/VPS et donc
ça sera pareil pour les VPS, c'est à dire 100% de PCI et VPS
seront protégés 24/24.
On est en train de terminer le VAC4 pour GRA en se basant
sur le vR + Anti-DDoS. Le VAC4 sera comme le VAC1/2/3
sauf qu'il coutera 10% du prix. On va pouvoir donc le déployer
massivement dans nos 12 nouveaux DCs, sans limite de
capacité de traitement. On parle de VAC5 à VAC16 dans
les 18 mois à venir.
Amicalement
Octave
Россия взяла "бронзу" по количеству ddos-атак
Россия взяла «бронзу» по количеству ddos-атак
Уступив Китаю и США
За 2015 год на клиентов DDoS-GUARD было совершено более 50 тысяч ddos-атак. То есть в среднем система защиты фильтровала по 5 атак в час. При этом хакеры не особо усердствовали, выискивая новые уязвимости, а сделали ставку на комбинированные атаки — продолжительный флуд средней мощности с периодическими мощными «тычками», длящимися буквально секунду. Такая тактика характерна для ddos-еров из Китай. Эта страна, кстати, заняла первое место в антирейтинге стран-«жертв» паразитного трафика.
Эти и другие итоги 2015 года представлены в инфографике:
Читать дальше →
Уступив Китаю и США
За 2015 год на клиентов DDoS-GUARD было совершено более 50 тысяч ddos-атак. То есть в среднем система защиты фильтровала по 5 атак в час. При этом хакеры не особо усердствовали, выискивая новые уязвимости, а сделали ставку на комбинированные атаки — продолжительный флуд средней мощности с периодическими мощными «тычками», длящимися буквально секунду. Такая тактика характерна для ddos-еров из Китай. Эта страна, кстати, заняла первое место в антирейтинге стран-«жертв» паразитного трафика.
Эти и другие итоги 2015 года представлены в инфографике:
Читать дальше →
Вчера благополучно отразили DDoS-атаку на клиентские серверы
Атака шла с 14:30 до 21:17, 38 Гбит/сек, 10 mppc, udp amplification + tcp syn flood
selectel.ru/services/ddos-protection/
Казахстанский интернет защитят от ddos-атак бесплатно
DDoS-GUARD — российский провайдер защиты от ddos-атак — объявляет о начале сотрудничества с компанией Hoster.KZ. Это первый аккредитованный регистратор доменов .kz в Казахстане. Теперь все клиенты хостера смогут воспользоваться сервисом защиты от DDoS-атак, причем бесплатно — тест продлится до конца года.
- Для всех клиентов подключена автоматическая защита от DDoS-атак. До конца 2015 года услуга предоставляется бесплатно и работает для всех наших клиентов на виртуальном хостинге, VPS хостинге и на выделенных серверах. Можно назвать этот период тестовым, — официально заявил Денис Сухачев, директор Hoster.KZ, — Сейчас, в первую очередь, мы защищаем нашу инфраструктуру от внешних атак. Самый популярный случай — атака идет на ip-адрес сервера, на котором размещаются сотни и тысячи клиентов. Вычислить настоящую «жертву» достаточно сложно, страдают все. И я искренне уверен, что это на для нас и для наших клиентов в прошлом.
- Мы постоянно работаем над расширением географии поставки наших услуг. Казахстан — это перспективное направление. Ведь там, где активно развивается Интернет, возрастает хакерская активность. А значит, нужна надежная система защиты, доступная по стоимости не только крупным компаниям, но и малому бизнесу. Мы рады, что Hoster.KZ выбрали именно нас в качестве партнера в вопросе кибербезопасности, — прокомментировал Дмитрий Сабитов, коммерческий директор DDoS-GUARD.
Продаем или меняем оборудование Radware Defence Pro для защиты от ддос атак
В связи со сменой оборудования для защиты от ддос атак на продажу выставляем следующее оборудование:
Radware Defence Pro 12412 Полная лицензия на 12Gb/s, IPS & Behavioral Protection — цена 20.000$ или обменяем ее на сеть /21. В наличии одна железка. Официальный прайс свыше 200.000 евро.
www.bifit.ru/ru/BIFIT_DefensePro.pdf
Radware Defence Pro 3020, Полная лицензия. В практике защищает от 4Mpps syn flood. — цена 5000$ или обменяем ее на сеть /23. В наличии 4 штуки. Все 4 штуки обменяем можем обменять на /21. У нас все 4 штуки стояли в параллели и фильтровали до 16Mpps syn flood.
Если берете все 5 железок, соответственно обменяем на сеть /20
Готовы продать как за нал/безнал. Для реальных покупателей перед покупкой готовы подключить железки к интернету и дать доступ для проверки.
Более точное описание ищите у офф производителей.
Сайт нашей компании: http://artplanet.su ДЦ в Санкт-Петербурге, Телефоны: +7 (499) 403-32-96, +7 (812) 424-78-07
Radware Defence Pro 12412 Полная лицензия на 12Gb/s, IPS & Behavioral Protection — цена 20.000$ или обменяем ее на сеть /21. В наличии одна железка. Официальный прайс свыше 200.000 евро.
www.bifit.ru/ru/BIFIT_DefensePro.pdf
Radware Defence Pro 3020, Полная лицензия. В практике защищает от 4Mpps syn flood. — цена 5000$ или обменяем ее на сеть /23. В наличии 4 штуки. Все 4 штуки обменяем можем обменять на /21. У нас все 4 штуки стояли в параллели и фильтровали до 16Mpps syn flood.
Если берете все 5 железок, соответственно обменяем на сеть /20
Готовы продать как за нал/безнал. Для реальных покупателей перед покупкой готовы подключить железки к интернету и дать доступ для проверки.
Более точное описание ищите у офф производителей.
Сайт нашей компании: http://artplanet.su ДЦ в Санкт-Петербурге, Телефоны: +7 (499) 403-32-96, +7 (812) 424-78-07